home *** CD-ROM | disk | FTP | other *** search
/ Collection of Internet / Collection of Internet.iso / infosrvr / dev / www_talk.930 / 000526_connolly@pixel.convex.com _Fri Jan 8 19:35:55 1993.msg < prev    next >
Internet Message Format  |  1994-01-24  |  3KB
  1. Return-Path: <connolly@pixel.convex.com>
  2. Received: from dxmint.cern.ch by  nxoc01.cern.ch  (NeXT-1.0 (From Sendmail 5.52)/NeXT-2.0)
  3.     id AA01737; Fri, 8 Jan 93 19:35:55 MET
  4. Received: by dxmint.cern.ch (5.65/DEC-Ultrix/4.3)
  5.     id AA29860; Fri, 8 Jan 1993 19:50:54 +0100
  6. Received: from pixel.convex.com by convex.convex.com (5.64/1.35)
  7.     id AA03545; Fri, 8 Jan 93 12:50:50 -0600
  8. Received: from localhost by pixel.convex.com (5.64/1.28)
  9.     id AA27549; Fri, 8 Jan 93 12:50:49 -0600
  10. Message-Id: <9301081850.AA27549@pixel.convex.com>
  11. To: timbl@nxoc01.cern.ch
  12. Cc: "Thomas A. Fine" <fine@cis.ohio-state.edu>, www-talk@nxoc01.cern.ch
  13. Subject: Re: dealing with new-lines 
  14. In-Reply-To: Your message of "Fri, 08 Jan 93 12:09:41 +0100."
  15.              <9301081109.AA02814@www3.cern.ch> 
  16. Date: Fri, 08 Jan 93 12:50:48 CST
  17. From: Dan Connolly <connolly@pixel.convex.com>
  18.  
  19.  
  20. >For what it is worth, the way the CERN implementations are supposed to work is:
  21. >
  22. >This means that any number of newlines  
  23. >will only produce one white space character.  [It involves a horrid "are we in
  24. >the middle of a word?" flag.]
  25.  
  26. I don't think this flag is "horrid." It's a pretty normal text-formatting
  27. thing to do.
  28.  
  29. >Spaces, however, always produce spaces, so multiple spaces will come out as  
  30. >multiple spaces.
  31.  
  32. Is anyone distressed by the situation where some browsers compress
  33. multiple spaces [in typeset paragraphs] into one, and some do not? I'm not.
  34. I'd say "Don't do that" to the fool who put multiple spaces in
  35. his source.
  36.  
  37. >    XMP
  38. >    
  39. >Within <XMP> I went all the way and said that from the trailing > of <XMP>
  40. >to the beginning <of </XMP> all data was litteral, including newlines.  
  41. >Therefore example sections typically are marked up as
  42. >
  43. ><XMP>This is an example line
  44. >
  45. ></XMP>
  46. >That was an example.  There are no new lines between the <XMP> and the example
  47. >line because the XMP section causes a paragraph break, and the style for the  
  48. >normal paragraph specifies a minimum white space after each paragraph.
  49.  
  50. This looks like sound policy to me.
  51.  
  52. > Beacuse
  53. >each XMP section is like a black box, any white spce inside it would not be  
  54. >seen by the white space management logic which overlaps the white spaces  
  55. >required around successive paragraphs, and extra white spce would result.
  56.  
  57. Unfortunately, this conflicts with the SGML standard. An SGML parser
  58. will report
  59. <XMP>
  60. foo
  61. </XMP>
  62.  
  63. as
  64. an XMP start tag
  65. the string "foo" [NOT "\nfoo\n"]
  66. an XMP end tag
  67.  
  68. And so it is, strictly speaking, illegal to treat the above markup
  69. differently from
  70. <XMP>foo</XMP>
  71.  
  72. I'm not sure how we should resolve this.
  73.  
  74. >    PRE
  75. >
  76. >By the way, I think we agreed (I gave in) that the <PRE> sections would have
  77. >siugnificant newlines.  Your manuals, Tom, have <p> as well as newlines, which
  78. >gives double spacing on my browsers.  So I tread newlines as newlines in all
  79. >the <PRE> element just as XMP.
  80.  
  81. This is a situation we need to resolve, one way or another. I'm inclined
  82. to decide that <p> elements are allowed in PRE elements, but they have
  83. no significance. They were put there to cause the old linemode browser
  84. to break the line, so they have always been redundant. So Tim's treatment
  85. of newlines in PRE is correct, but his treatment of <P> there is not
  86. [by this new convention.]
  87.  
  88. Dan
  89.